@swift-ci please test

@Kyle-Ye @QuietMisdreavus I've just rebased this PR on master, and all the tests (at least the ones that I can see) now pass. Would it be possible to get this merged?

@swift-ci please test

We are actually using GFM. So I believe we should refer into this spec

I was just about to link that, yeah

One more issue is for "___a___" or "***a***" input. If we specify emphasisMarker to be "_" and strongEmphasisMarker to be "*".

The result would be "_**a**_".

The order is expected but I do not see spec covers such usage. Can you provide some insights on this?

What specifically is your question? The ordering or whether it is allowed to have two different types of delimiters next to each other?

The ordering should be addressed by Example 476, and the fact that you are allowed to have different delimiters right next to each other is addressed by Example 472

What specifically is your question? The ordering or whether it is allowed to have two different types of delimiters next to each other?

different emphasis marker and strong emphasis right next to each other

The ordering should be addressed by Example 476

I have no problem of the ordering as it has been explicitly stated in the spec "An interpretation <em><strong>...</strong></em> is always preferred to <strong><em>...</em></strong>".

and the fact that you are allowed to have different delimiters right next to each other is addressed by Example 472

No. Example 472 does not address my issue. I have not seen any spec statement or example of "<em><strong>...</strong></em>" written as "_**{content}**_" or "*__{content}__*".

Ah, I see what you are asking. I'll give two examples.

1. _**a**_ (which GitHub renders properly as a)

In this case, the first _ is a left-flanking delimiter run because it is a delimiter run 1) not followed by unicode whitespace and 2b) followed by a punctuation character and preceded by unicode whitespace (the start of line). The first ** is a left-flanking delimiter run because it is a delimiter run 1) not followed by unicode whitespace and 2a) not followed by a punctuation character.

The second ** is a right-flanking delimiter run because it is a delimiter run 1) not preceded by unicode whitespace and 2a) not preceded by a punctuation character. The second _ is a right-flanking delimiter run because it is a delimiter run 1) not preceded by unicode whitespace and 2b) preceded by a punctuation character and followed by unicode whitespace (the end of line).

The first _ can open emphasis because it is part of a left-flanking delimiter run and a) not part of a right-flanking delimiter run. The first ** can open strong emphasis because it is part of a left flanking delimiter run.

The second ** can close strong emphasis because it is part of a right flanking delimiter run. The second _ can close emphasis because it is part of a right-flanking delimiter run and a) not part of a left-flanking delimiter run

1. "_**a**_" (which GitHub renders properly as "a")

In this case, the first _ is a left-flanking delimiter run because it is a delimiter run 1) not followed by unicode whitespace and 2b) followed by a punctuation character and preceded by a punctuation character. The first ** is a left-flanking delimiter run because it is a delimiter run 1) not followed by unicode whitespace and 2a) not followed by a punctuation character.

The second ** is a right-flanking delimiter run because it is a delimiter run 1) not preceded by unicode whitespace and 2a) not preceded by a punctuation character. The second _ is a right-flanking delimiter run because it is a delimiter run 1) not preceded by unicode whitespace and 2b) preceded by a punctuation character and followed by a punctuation character.

The first _ can open emphasis because it is part of a left-flanking delimiter run and a) not part of a right-flanking delimiter run. The first ** can open strong emphasis because it is part of a left flanking delimiter run.

The second ** can close strong emphasis because it is part of a right flanking delimiter run. The second _ can close emphasis because it is part of a right-flanking delimiter run and a) not part of a left-flanking delimiter run

@Kyle-Ye hopefully that addresses your question. I do wish that they had examples, though

@Kyle-Ye hopefully that addresses your question. I do wish that they had examples, though

Got it. They are indeed grammatically correct. Just hoping we go a example in the spec though. LOL

I think that latest commit should address your other concern — let me know if you'd like any other changes to be made

@swift-ci test

I feel like combined emphasis and strong emphasis should all be rendered with the strong emphasis marker, but that requires that visitEmphasis checks its immediate parent and/or child to see if it's part of a combination emphasis.

That would look something like this:

    public mutating func visitEmphasis(_ emphasis: Emphasis) {
        let emphasisMarker: String
        if let parent = emphasis.parent as? Strong, parent.childCount == 1 {
            emphasisMarker = formattingOptions.strongEmphasisMarker.rawValue
        } else if emphasis.childCount == 1, emphasis.child(at: 0) is Strong {
            emphasisMarker = formattingOptions.strongEmphasisMarker.rawValue
        } else {
            emphasisMarker = formattingOptions.emphasisMarker.rawValue
        }
        print(emphasisMarker, for: emphasis)
        descendInto(emphasis)
        print(emphasisMarker, for: emphasis)
    }

And then adding more tests to make sure that combination emphasis works as expected.

This way, we don't have to worry about semantics surrounding mixed emphasis markers. Even though we correctly parse the mixed result, it will look better in the rendered output to have these mixed emphasis spans use the same marker, even if we've been given separate emphasis markers.

I feel like combined emphasis and strong emphasis should all be rendered with the strong emphasis marker

I think this would be unexpected behavior. When the strong emphasis marker and normal emphasis marker are both set, the former should be used for strong emphasis, and the latter should be used for normal emphasis.

This way, we don't have to worry about semantics surrounding mixed emphasis markers. Even though we correctly parse the mixed result, it will look better in the rendered output to have these mixed emphasis spans use the same marker, even if we've been given separate emphasis markers.

Personally, I would still prefer my output to use different strong and normal emphasis markers even when they are both in use. I think this PR shouldn't include special cases where it diverges from the behavior one would expect when specifying two different emphasis markers

Unless there are any other concerns, would it be possible to merge this?

+1. cc @QuietMisdreavus